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Abstract. Abstraction- Carrying Code (ACC) has recently been pro- 
posed as a framework for proof-carrying code (PCC) in which the code 
supplier provides a program together with an abstraction (or abstract 
model of the program) whose validity entails compliance with a prede- 
fined safety policy. The abstraction thus plays the role of safety certifi- 
cate and its generation (and validation) is carried out automatically by a 
fixed-point analyzer. Existing approaches for PCC are developed under 
the assumption that the consumer reads and validates the entire program 
w.r.t. the full certificate at once, in a non incremental way. In this ab- 
stract, we overview the main issues on incremental ACC. In particular, 
in the context of logic programming, we discuss both the generation of 
incremental certificates and the design of an incremental checking algo- 
rithm for untrusted updates of a (trusted) program, i.e., when a producer 
provides a modified version of a previously validated program. By up- 
date, we refer to any arbitrary change on a program, i.e., the extension 
of the program with new predicates, the deletion of existing predicates 
and the replacement of existing predicates by new versions for them. We 
also discuss how each kind of update affects the incremental extension 
in terms of accuracy and correctness. 



1 Introduction 

Proof-Carrying Code (PCC) [11] is a general technique for mobile code safety 
which proposes to associate safety information in the form of a certificate to 
programs. The certificate (or proof) is created at compile time by the certifier 
on the code supplier side, and it is packaged along with the code. The consumer 
who receives or downloads the (untrusted) code+certificate package can then 
run a checker which by an efficient inspection of the code and the certificate can 
verify the validity of the certificate and thus compliance with the safety policy. 
The key benefit of this "certificate-based" approach to mobile code safety is that 
the consumer's task is reduced from the level of proving to the level of checking, 
a task which should be much simpler, efficient, and automatic than generating 
the original certificate. 

Abstraction-carrying code (ACC) [2] has been recently proposed as an en- 
abling technology for PCC in which an abstraction (i.e., an abstract model of 
the program) plays the role of certificate. An important feature of ACC is that 



not only the checking, but also the generation of the abstraction (or fixpoint) is 
automatically carried out by a fixed-point analyzer. Lightweight bytecode verifi- 
cation [f 2] is another PCC method which relies on analysis techniques (namely 
on type analysis in the style of those used for Java bytecode verification [8]) 
to generate and check certificates in the context of the Java Card language. In 
this paper, we will consider analyzers which construct a program analysis graph 
which is interpreted as an abstraction of the (possibly infinite) set of states ex- 
plored by the concrete execution. Essentially, the certification/analysis carried 
out by the supplier is an iterative process which repeatedly traverses the analysis 
graph until a fixpoint is reached. A key idea in ACC is that, since the certificate 
is a fixpoint, a single pass over the analysis graph is sufficient to validate the 
certificate in the consumer side. 

Existing models for PCC (ACC among them) are based on checkers which 
receive a "certificate+program" package and read and validate the entire pro- 
gram w.r.t. its certificate at once, in a non incremental way. However, there are 
situations which are not well suited to this simple model and which instead re- 
quire only rechecking certain parts of the analysis graph which has already been 
validated. In particular, we consider possible untrusted updates of a validated 
(trusted) code, i.e., a code producer can (periodically) send to its consumers new 
updates of a previously submitted package. We characterize the different kind 
of updates, or modifications over a program. In particular, we include: 

1. the addition of new data/predicates and the extension of already existing 
predicates with new functionalities, 

2. the deletion of predicates or parts of them and 

3. the replacement of certain (parts of) predicates by new versions for them. 

In such a context of frequent software updates, it appears inefficient to submit 
a full certificate (superseding the original one) and to perform the checking of the 
entire updated program from scratch, as needs to be done with current systems. 
In the context of ACC, we discuss the influence of the different kinds of updates 
on an incremental extension to PCC in terms of correctness and efficiency. We 
also outline the main issues on the generation of incremental certificates and the 
design of incremental checkers. 

The paper is organized as follows. Section 2 introduces briefly some notation 
and preliminary notions on abstract interpretation and ACC. In Section 3, we 
present a general view of incremental ACC. In Section 4 we describe the different 
kinds of updates over a program and the way they affect the certification and 
checking phases. Section 5 reviews the notion of full certificate and proposes the 
use of incremental certificate. In Section 6, we discuss the extensions needed on 
a non-incremental checking algorithm in order to support incrementality and we 
sketch the new tasks of an incremental checking algorithm. Finally, Section 7 
concludes. 



2 Abstraction-Carrying Code 



Our work relies on the abstract interpretation-based analysis algorithm of [6] 
for (Constraint) Logic Programming, (C)LP. We assume some familiarity with 
abstract interpretation (see [5]), (C)LP (see, e.g., [9,10]) and PCC [11]. 

Very briefly, terms are constructed from variables (e.g., x), functors (e.g., /) 
and predicates (e.g., p). We denote by {x\ i— ► t\, . . . , x n i— ► i n } the substitution 
a, where Xi ^ Xj, if i ^ j, and U are terms. A renaming is a substitution p for 
which there exists the inverse p~ x such that pp~ x = p~ x p= id. A constraint is a 
conjunction of expressions built from predefined predicates (such as inequalities 
over the reals) whose arguments are constructed using predefined functions (such 
as real addition) . An atom has the form p(t\ , .. ., t n ) where p is a predicate symbol 
and ti are terms. A literal is either an atom or a constraint. A rule is of the form 
H : -D where H, the head, is an atom and D, the body, is a possibly empty finite 
sequence of literals. A constraint logic program P G Prog, or program, is a finite 
set of rules. Program rules are assumed to be normalized: only distinct variables 
are allowed to occur as arguments to atoms. Furthermore, we require that each 
rule defining a predicate p has identical sequence of variables x Pl , . . . x Pn in the 
head atom, i.e., p(x Pl , . . . x Pn ) . We call this the base form of p. This is not 
restrictive since programs can always be normalized. 

An abstract interpretation-based certifier is a function Certifier: Prog x 
ADom x AInt *—> ACert which for a given program P G Prog, an abstract 
domain D a G ADom and an abstract safety policy I a G AInt generates an 
abstract certificate Cert a G ACert, by using an abstract interpreter for D a , 
such that the certificate entails that P satisfies I a . An abstract safety policy 
I a is a specification of the safety requirements given in terms of the abstract 
domain D a . In the following, using the same subscript a, we denote that I a and 
Cert a are specifications given as abstract semantic values of D a . 

The basics for defining such certifiers (and their corresponding checkers) in 
ACC are summarized in the following five points: 

Approximation. We consider a description (or abstract) domain (D a ,Q) G 
ADom and its corresponding concrete domain (2 D , C), both with a com- 
plete lattice structure. Description (or abstract) values and sets of concrete 
values are related by an abstraction function a : 2 D — > D a , and a con- 
cretization function 7 : D a — > 2 D . The pair (a, 7} forms a Galois connection. 
The concrete and abstract domains must be related in such a way that the 
following condition holds [5] 

Vx G 2 D : j(a(x)) 2 x and Vy G D a : a(j(y)) = y 

In general C is induced by C and a. Similarly, the operations of least upper 
bound (U) and greatest lower bound (n) mimic those of 2 D in a precise sense. 

Analysis. We consider the class of fixed-point semantics in which a (monotonic) 
semantic operator, Sp, is associated to each program P. The meaning of the 
program, [PJ, is defined as the least fixed point of the Sp operator, i.e., 



[P] = lfp(S'p). If Sp is continuous, the least fixed point is the limit of an 
iterative process involving at most u applications of Sp starting from the 
bottom element of the lattice. Using abstract interpretation, we can usually 
only compute [P] a , as [PJ Q = lfp(Sp). The operator Sp is the abstract 
counterpart of Sp. 

analyzer(P,AO=lfp(S£) = Pl Q (1) 
Correctness of analysis ensures that [P]] Q safely approximates [P]], i.e., 
[[PJ £ 7([[PJ Q )- Thus, such abstraction can be used as a certificate. 

Certificate. Let Cert a be a safe approximation of |P]] Q . If an abstract safety 
specification I a can be proved w.r.t. Cert a , then P satisfies the safety policy 
and Cert a is a valid certificate: 

Cert a is a valid certificate for P w.r.t. I a iff Cert a E P* (2) 

Note that the certificate can be stricter than the safety specification and it 
is only required that I a is implied by Cert a . 

Certifier. Together, Equations (1) and (2) define a certifier which provides 
program fixpoints, [[PJ Q , as certificates which entail a given safety policy, 
i.e., by taking Cert a = [P]] a . 

Checking. A checker is a function Checker: Prog x ADom x ACert i— > bool 
which for a program P e Prog, an abstract domain P Q e ADom and cer- 
tificate Certa 6 ACert checks whether Cert a is a fixpoint of S'p or not: 

CHECKER(P, D a , Cert a ) returns true iff (Sp(Cert a ) = Cert a ) (3) 

Verification Condition Regeneration. To retain the safety guarantees, the 
consumer must regenerate a trustworthy verification condition -Equation 
(2)- and use the incoming certificate to test for adherence of the safety 
policy. 

P is trusted iff Cert a E I a (4) 

A fundamental idea in ACC is that, while analysis -Equation (1)- is an 
iterative process, checking -Equation (3)- is guaranteed to be done in a 
single pass over the abstraction. 



3 A General View of Incremental ACC 

Figures 1 and 2 present a general view of the incremental certification and incre- 
mental checking processes respectively. In Figure 1, the producer starts from an 
Updated Program, Up, w.r.t. a previously certified Program, P. It first retrieves 
from disk P and its certificate, Cert, computed in the previous certification phase. 
Next, the process "0" compares both programs and returns the differences be- 
tween them, Upd(P), i.e, the program Updates which applied to P results in 



Up, written as Upd(P) — Up P. Note that, from an implementation per- 
spective, a program update should contain both the new updates to be applied 
to the program and instructions on where to place and remove such new code. 
This can be easily done by using the traditional Unix diff format for coding 
program updates. An Incremental Certifier generates from Cert, P and Upd(P) 
an incremental certificate, lnc_Cert, which can be used by the consumer to vali- 
date the new updates. The package u Upd(P)+\nc_Cert" is submitted to the code 
consumer. Finally, in order to have a compositional incremental approach, the 
producer has to update the original certificate and program with the new up- 
dates. Thus, the resulting Ext.Cert and Up are stored in disk replacing Cert and 
P, respectively. 
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Fig. 1. Incremental Certification in Abstraction-Carrying Code 



In Figure 2, the consumer receives the untrusted package. In order to validate the 
incoming update w.r.t. the provided (incremental) certificate, it first retrieves P 
and Cert from disk. Next, it reconstructs the updated program by using an oper- 
ator "©" which applies the update to P and generates Up = P © Upd(P). This 
can implemented by using a program in the spirit of the traditional Unix patch 
command as operator. An Incremental Checker now efficiently validates the 
new modification by using the stored data and the incoming incremental certifi- 
cate. If the validation succeeds (returns ok), the checker will have reconstructed 
the full certificate. As before, the updated program and extended certificate are 
stored in disk (superseding the previous versions) for future (incremental) up- 
dates. In order to simplify our scheme, we assume that the safety policy and 
the generation of the verification condition [11] are embedded within the certi- 
fier and checker. However, in an incremental approach, producer and consumer 
could perfectly agree on a new safety policy to be implied by the modification. 
It should be noted that this does not affect our incremental approach and the 
verification condition would be generated exactly as in non incremental PCC. 




Fig. 2. Incremental Checking in Abstraction-Carrying Code 



4 Characterization of Updates 

Let us now characterize the types of updates we consider and how they can 
be dealt within the ACC scheme in the context of logic programming. Given a 
program P, we define an update of P, written as Upd(P), as a set of tuples of 
the form {A, Add (A), Del(A)), where A = p(x\, . . . , x n ) is an atom in base form 
and: 

— Add(A) is the set of rules which are to be added to P for predicate p. This 
includes both the case of addition of new predicates, when p did not exist 
in P, as well as the extension of additional rules (or functionality) for p, if 
it existed. 

— Del(A) is the set of rules which are to be removed from P for predicate p. 

Note that, for the sake of simplicity, we do not include the instructions on where 
to place and remove such code in the formalization of our method. We distinguish 
three classes of updates: addition, deletion and arbitrary changes. 

— The addition of predicates occurs when \/A, Del(A) = A 3A, Add(A) ^ 0. 

— The deletion of predicates occurs if VA, Add(A) = A 3A, Del(A) ^ 0. 

— The remaining cases are considered arbitrary changes. 



Addition of Procedures. When a program P is extended with new predicates 
or new clauses for existing predicates, the original certificate C'ert a is not 
guaranteed to be a fixpoint any longer, because the contribution of the new 
rules can lead to a more general answer. Consider p add the program after 
applying some additions and Cert add the certificate computed from scratch 
for p add . Then, Cert a C Cert add . This means that Cert a is no longer valid. 
Therefore, we need to perform the least upper bound (lub) of the contri- 
bution of the new rules and submit, together with the extension, the new 



certificate Cert add (or the difference of both certificates). The consumer will 
thus test the safety policy w.r.t. Cert add . Consider the abstract operation 
Alub(CPi, CP2) which performs the abstract disjunction of two descriptions. 
Then, we define Cert a a dd = Mub(Cert a , [P acW ]] Q ) and submit the incremental 
certificate Cert which is defined as the (abstract) difference Cert^ dd — Cert a . 
The notion of incremental certificate is the issue of Section 5. 

Deletion of Procedures. The first thing to note is that in order to entail the 
safety policy, unlike extensions over the program, we need not change the cer- 
tificate at all when some predicates are deleted. Consider P del the program 
after applying some deletions and Cert^ 1 the certificate computed from 
scratch for P del . The original certificate C'ert a is trivially guaranteed to be 
a fixpoint (hence a correct certificate), because the contribution of the rules 
was conjoined (by computing the lub) to give Cert a and so it still correctly 
describes the contribution of each remaining rule. By applying Equation 2, 
Cert a is still valid for P del w.r.t. I a since Cert a C I a . Therefore, more accu- 
racy is not needed to ensure compliance with the safety policy. This suggests 
that the incremental certificate can be empty and the checking process does 
not have to check any predicate. However, it can happen that a new, more 
precise, safety policy is agreed by the consumer and producer. Also, this ac- 
curacy could be required in a later modification. Although Cert a is a correct 
certificate, it is possibly less accurate than Cert^ 1 , i.e., Cert del C Cert a . 
It is therefore interesting to define the corresponding incremental algorithm 
for reconstructing Cert del and checking the deletions and the propagation 
of their effects. 

Arbitrary Changes. The case of arbitrary changes considers that rules can 
both be deleted from and added to an already validated program. In this 
case, the new certificate for the modified program can be cither equal, more 
or less precise than the original one, or even not comparable. Imagine that an 
arbitrary change replaces a rule R a , which contributes to a fixpoint Certf^, 
with a new one Rb which contributes to a fixpoint Cert b a such that Certf^ = 
k\ub(Cert a a ,Cert b a ) and Cert a a C Certf and Cert b a C Certf . The point is 
that we cannot just compute an approximation of the new rule and compute 
the lub with to the previous fixpoint, i.e., we cannot use Cert^ as certificate 
and have to provide the more accurate Cert b a . The reason is that it might 
be possible to attest the safety policy by independently using Cert a a and 
Cert b a while it cannot be implied by using their lub Cert^. This happens 
for certain safety policies which contain disjunctions, i.e., C ert^W C ert b a does 
not correspond to their lub Cert^. Therefore, arbitrary changes require a 
precise recomputation of the new fixpoint and its proper checking. 
As a practical remark, an arbitrary update can be decomposed into an addi- 
tion and a deletion and then handled as the first cases. We have pointed out 
the difference because correctness and accuracy requirements arc different 
in each particular case, as we have seen above. 



Example 1. The next example shows a piece of a module which contains the 
following (normalized) program for the naive reversal of a list and uses the 
standard implementation of app for appending lists: 

'(rev 1 )rev(X,Y):-X=[], Y = [ ]. 
= I (rev 2 ) rev(X,Y) : - X = [U|V], rev(V,W), T = [U], app(W,T,Y). 
" ] (ap Pl ) app(X,Y,Z) :- X = [], Y = Z. 

k (app 4 ) app(X,Y,Z) : - X = [U|V], Z = [U|W], app(V,Y,W). 

Suppose now that the consumer modifies P introducing two more base cases for 
app (e.g., added automatically by a partial evaluator [7]): 

(app 2 ) app(X,Y,Z) : - X = [U], Z = [U|Y]. 
(app 3 ) app(X,Y,Z) : -X = [U,V], Z = [U,V|Y]. 

The producer must send to the consumer the set Upd(Po), composed of the 
unique tuple: 

(app(X, Y, Z), ^dd(app(X, Y, Z)), L>eZ(app(X, Y, Z))) 

where Add(a.pp(X 7 Y, Z)) = {app 2 ,app 3 } and PeZ(app(X, Y, Z)) = 0, i.e., we are 
in the case of an addition of predicates only. Let us name Pi to the program 
resulting from adding rules app 2 and app 3 to Po. Note that these rules do not 
add any further information to the program (i.e., the certificate for Po and Pi 
would remain the same and, as we will see, the incremental certificate is empty). 

Consider now the following new definition for predicate app which is a spe- 
cialization of the previous app to concatenate lists of a's of the same length: 

(NappO app(X,Y,Z) : - X = [],Y= [],Z = []. 

(Napp 2 ) app(X,Y,Z) : - X = [a|V], Y = [a|U], Z = [a, a|W], app(V, U, W). 

The update consists in deleting all rules for predicate app in Pi and replacing 
them by Nappi and Napp 2 . Let P2 be the resulting program. Upd(Pi ) is composed 
again of a unique tuple with the following information: 

Add(app(X,Y,Z)) = {Nap Pl ,Napp 2 } 
PeZ(app(X, Y, Z)) = {app l5 app 2 , app 3 , app 4 } 

In this case, we are in presence of an arbitrary change, and as we will show in 
Example 5, the incremental certificate will not be empty in this case (since by 
using the abstract domain Def in Example 2, the fixpoint for P2 will change 
w.r.t. the one for Pi). □ 

5 Incremental Certificates 

Although ACC and incremental ACC, as outlined above, are general proposals 
not tied to any particular programming paradigm, our developments for incre- 
mental ACC (as well as for the original ACC framework [2]) are formalized 



in the context of (C)LP. A main idea in ACC [2] is that a certificate, Cert, is 
automatically generated by using the complete set of entries returned by an 
abstract fixpoint analysis algorithm. For concreteness, we rely on an abstract 
interpretation-based analysis algorithm in the style of the generic analyzer of 
[6]. 

The analysis algorithm of [6] , which we refer to as Analyze, given a program 
P and an abstract domain D a , receives a set of call patterns S a £ A Atom (or 
Abstract Atoms) which are a description of the calling modes into the program, 
and constructs an analysis graph [4] for S a which is an abstraction of the (pos- 
sibly infinite) set of (possibly infinite) trees explored by the concrete execution 
of initial calls described by S a in P. Formally, a call pattern A : CP 6 AAtom 
is composed of an atom in base form, A = p(X\, . . . , X n ), and a description in 
the abstract domain, CP, for A. 

The program analysis graph computed by Analyze(5 q ) for P in D a can be 
implicitly represented by means of two data structures, the answer table (AT) 
and the dependency arc table (DAT), which are the output of the algorithm 
Analyze. Each element (or entry) in the answer table takes the form A : CP i— ► 
AP such that, for the atom A, CP is its call description and AP its success 
(or answer) description in the abstract domain. Informally, such entry should 
be interpreted as "the answer pattern for calls to A satisfying precondition CP 
accomplishes postcondition AP" . The dependency arc table is not relevant now, 
although it is fundamental in the design of the incremental checking, as we will 
see later. All the details and the formalization of the algorithm can be found in 
[6]. 

Our proposal for the incremental checking is that, if the consumer keeps the 
original (fixed-point) abstraction Cert, it is possible to provide only the program 
updates and the incremental certificate lnc_Cert. Concretely, given: 

— an update Upd(P) of P, 

— the certificate Cert for P and S a , 

— the certificate Ext.Cert for P® Upd(P) and S a 

wc define lnc_Cert, the incremental certificate for Upd(P) w.r.t. Cert, as the 
difference of certificates Ext.Cert and Cert, i.e., the set of entries in Ext.Cert not 
occurring in Cert. The first obvious advantage is that the size of the transmitted 
certificate can be considerably reduced. Let us see an example. 

Example 2. Consider program P$ in Example 1. The description domain that 
we are going to use in our examples is the definite Boolean functions [3], de- 
noted Def. The key idea in this description is to use implication to capture 
groundness dependencies. The reading of the function x — > y is "if the program 
variable x is (becomes) ground, so is (does) program variable y." For example, 
the best description of the constraint f (X, Y) = f (a, g(U, V)) is X A (Y <-► (U A V)). 
The most general description T does not provide information about any vari- 
able. The least general substitution _L assigns the empty set of values to each 
variable. For the analysis of our running example, we consider the set of call 



patterns S a = {rev(X, Y) : T}, i.e., no entry information is provided on X nor Y. 
ANALYZE({rev(X, Y) : T}) returns in the answer table, AT, the following entries: 

(Ai) rev(X, Y) : T h X h Y 

{A 2 ) app(X, Y, Z) : T (X A Y) h Z 

The certificate Cert for this example is then composed of the entries Aj and 
A 2 . Consider now the addition of rules app 2 and app 3 in P , i.e., program Pi of 
Example 1. The analysis algorithm of [6] returns as Ext_Cert the same answer 
table AT as for P n , since the added rules do not affect the fixpoint result, i.e., 
they do not add any further information. Thus, the incremental certificate lnc_- 
Cert associated to such an update is empty. □ 

6 Incremental Checking 

Intuitively, an abstract interpretation-based checking algorithm (like the one in 
[2]) receives as input a program P, a set of abstract atoms S a and a certificate 
Cert and constructs a program analysis graph in a single iteration by assum- 
ing the fixpoint information in Cert. While the graph is being constructed, the 
obtained answers are stored in an answer table AT mem (initially empty) and 
compared with the corresponding fixpoints stored in Cert. If any of the com- 
puted answers is not consistent with the certificate (i.e., it is greater than the 
fixpoint), the certificate is considered invalid and the program is rejected. Oth- 
erwise, Cert gets accepted and AT mem = Cert. 

6.1 Checking with Dependencies 

In order to define an incremental checking, the checking algorithm in [2] needs 
to be modified to compute (and store) also the dependencies between the atoms 
in the answer table. In [1], we have instrumented a checking algorithm for full 
certificates with a Dependency Arc Table. This structure, DAT, is not required 
by non incremental checkers but it is fundamental to support an incremental de- 
sign. The DAT returned by Analyze is composed of arcs (or dependencies) of 
the form Ak ■ CP => Bk,i ■ CP' associated to a program rule Ak :- Bfe,i, • • • , Bk, n 
with i G {1, ..n}, where Bk t i is an atom. The intended meaning of such a depen- 
dency is that the answer for Ak ■ CP depends on the answer for Bk y i : CP', say 
AP. Thus, if AP changes with the update of some rule for Bks then, the arc 
Ak ■ CP =>■ Bk.i : CP' must be reprocessed in order to compute the new answer 
for Ak : CP. This is to say that the rule for Ak has to be processed again starting 
from atom Bks, i.e., we do not need to process the part Ak :- £?fc,i, • • • , Bks-i 
because it is not affected by the changes. 

In the following, we assume that checker is a non incremental checker such 
that, if the call CHECKER(P, S a , Cert) docs not fail, then it returns the recon- 
structed answer table AT mem and the set of dependencies DAT mem which have 
been generated. In such a case, we say that Cert has been checked or accepted. By 
the correctness of the checker [2], the reconstructed structures contain exactly 



the same data as the answer table and the dependency arc table computed by 
the analysis algorithm Analyze(S q ) for the program P. 

Example 3. Consider the program P in Example 1. Analyze returns, together 
with AT, the following dependency arc table: 

(Dt) rev(X,Y) : T => rev(V,W) : T 
(D e ) rev(X,Y) : T app(W,T,Y) : T 
(A?) app(X,Y,Z) : T app(V,Y,W) : T 

Intuitively, D 2 denotes that the answer for rev(X, Y) : T may change if the answer 
for app(W, T, Y) : T changes. In such a case, the second rule rev 2 for rev must 
be processed again starting from atom app(W, T,Y) in order to recompute the 
fixpoint for rev(X,Y) : T. D\ and D3 reflect the recursivity of rev(X,Y) : T and 
app(W, T, Y) : T, respectively, since they depend on themselves (rules rev 2 and 
app 4 respectively) . The detailed steps performed by the algorithm can be found 
in [6]. Note that, the checker executed for the call pattern at hand, computes 
(and stores) in AT mem the entries A\, A 2 in Example 2, and, after traversing 
rules rev 2 and app 4 , it stores in DAT mem the dependencies D\, D 2 and D 3 . □ 

6.2 Additional Tasks of an Incremental Checker 

In order to support incrementality, the final values of the data structures AT mem , 
DAT mem and P must be available after the end of the execution of the checker. 
Thus, we denote by AT pers i S t, DAT pers i S t and P per sist the copy in persistent 
memory (i.e., in disk) of such structures. Now, we outline in a very general way 
the additional tasks that an incremental checking algorithm (inc_CHECK in the 
following) has to perform. The complete code of the algorithm can be found in 
[1]. It receives as input parameters an update Upd(P) of the original program 
P, a set of abstract atoms S a G A Atom and the incremental certificate lnc_Cert 
for Upd(P) w.r.t. Cert. The following tasks are carried out by an incremental 
checker: 

Step 1) It retrieves from memory AT mem := AT perslst , DAT mem := DAT persist 
and P := P per sist (stored in persistent memory in a previous checking phase) 
and generates P me m ■= P ® Upd(P). 

Step 2) It rechecks all entries in AT mem which have been directly affected by 
an update. Concretely, for each A : CP G AT mem , such that A has an entry 
in Upd(P), a call to CHECKEr(P© Upd(P), {A : CP}, Inc.Cert) is generated, 
marking the entry as checked (or accepted) A : (jp check _ This guarantees that 
the incremental checking process is done in one pass (i.e., rules used to check 
A : CP are traversed at most once) . 

Step 3) It propagates and rechecks the indirect effect of these changes by in- 
specting the dependencies in DAT mem . Thus, for all A : QP check G Inc.Cert, 
if there exists a dependency of the form B : CPb => A : CP (mod- 
ulo renaming) in DAT mem such that B : CPb is not marked as checked, 



then a call to CHECKER(P © Upd(P), {B : CP B }, lnc_Cert) is generated and 
B : CPb is marked as checked. This process is repeated until there are 
no dependencies satisfying the above condition. Note that the condition 
A : CP check e IncXert ensures that the answer for A : CP has changed 
w.r.t. Cert. Otherwise nothing has to be done (this will allow us to reduce 
the checking time w.r.t a full checking process for P and Ext_Cert). 

Step 4) If it does not issue an Error then it removes from AT mem those entries 
corresponding to deleted rules. We can identity them by exploring DAT mem . 
Concretely, for all A : CP £ AT mem , A : CP g" S a , if there not exists a 
dependency B : CP' A : CP in DAT mem then remove A : CP from 
A T mem . 

Step 5) It stores ATpersist . — AT mem7 BAP persist . — DAT mem and P persist • 
p 

1 mem • 

Our first example is intended to illustrate a situation in which the task performed 
by the incremental checker can be optimized such that it only checks a part of 
the analysis graph. 

Example 4- Consider the addition of rules app 2 and app3 to program Po, which 
results in program Pi (Example 1). As shown in Example 2, the incremental cer- 
tificate lnc_Cert associated to such an update is empty. The incremental checking 
algorithm INC_CHECK proceeds as follows: 

Step 1) AT mem and DAT mem arc initialized with A\,A 2 (Example 2) and 
Di,D 2 and D 3 (Example 3) respectively. P mem = P\. 

Step 2) Since app(X,Y, Z) : T g AT mem and ^4dd(app(X, Y, Z)) is not empty, 
then a call to CHECKER(Pi,{app(X, Y, Z) : T},lnc_Cert) is generated in order 
to ensure that the fixpoint is preserved. Now, app(X,Y, Z) : T is marked as 
checked. 

Step 3) No checking has to be done since lnc_Cert is empty. 

Step 4) Nothing is done since app(X,Y, Z) : T occurs at the right-hand side of 
dependency D%. 

Step 5) Finally, once lnc_Cert has been validated, the consumer stores the an- 
swer table AT mem , the dependency arc table DAT me m and the program 
Pmem m disk with the same values as in Step 1. □ 

Our second example is intended to show how to propagate the effect of a change 
to the part of the analysis graph indirectly affected by such update. 

Example 5. The update consists in deleting all rules for predicate app in program 
Pi of Example 1 (which results in program i-^), arid replacing them by Nappi 
and Napp 2 . After running the Analyze for P 2 , the following answer table and 
dependencies are computed: 



(NAi) 
(NA 2 ) 
(NA S ) 

(ND S ) 
(ND S ) 



rev(X, Y) :TmXAY 



app(X,Y,Z) :T^XAYAZ 
app(X, Y, Z) : X ^ X A Y A Z 
rev(X,Y) : T => rev(V,W) : T 



rev(X,Y) : T => app(W,T,Y) : W 
app(X, Y, Z) : X => app(V, U, W) : V 



Note that the analysis information has changed because the new definition of app 
allows inferring that all its arguments are ground upon success (NA 2 and NA S ). 3 
This change propagates to the answer of rev and allows inferring that, regardless 
of the call pattern, both arguments of rev will be ground on the exit (NAi). 
The incremental certificate lnc_Cert contains NAg as it corresponds to a new call 
pattern and contains also NAi and NA 2 since their answers have changed w.r.t. 
the ones stored in Cert (Example 2). Let us illustrate the incremental checking 
process carried out to validate this update. 

Step 1) We retrieve from disk the answer table, dependency arc table and the 
program stored in Step 5 of Example 4. Now P mem = f*2- 

Step 2) Similar to Step 2 of Example 4, but considering the new rules for app. 

Step 3) Since we have the dependency D 2 G DAT mem and app(X,Y, Z) : T e 
lnc_Cert, a call to CHECKER(P 2 ,{rev(X, Y) : T},lnc_Cert) is generated to en- 
sure that the new fixpoint for rev(X, Y) : T is valid. In the checking process, 
when traversing the rule rev 2 , the new call pattern app(X,Y, Z) : X occurs 
and it is also validated by calling to checker. When traversing rule Napp 2 , 
the dependency D$ is replaced by the new one ND3 in DAT memi and the 
call pattern is marked as checked. Similarly, the dependency D 2 is replaced 
by the new one ND 2 and rev(X, Y) : T is marked as checked. Now, all call 
patterns have been checked and the process finishes. 

Step 4) The entry NA2 is removed from AT mem since it does not occur at the 
right-hand side of any dependency. 

Step 5) The consumer stores the answer table AT mem := {NAj , NA 3 }, the de- 
pendency arc table DAT mem := {NDi , ND 2 , ND3 } and the program P mem :— 
P 2 in disk. □ 

The definition of the algorithm inc_CHECK can be found in [1], together with 
the proof of the correctness of the algorithm. Informally, correctness amounts 
to saying that if inc_CHECK docs not issue an error, then it returns as com- 
puted answer table the extended certificate Ext_Cert for the updated program. 
Moreover, we ensure that it does not iterate during the reconstruction of any 
answer. 

3 Note hat NA ;i is subsumed by NA2 and we could indeed only submit NA%. The 
incremental checking algorithm should be modified to search entries which are equal 
or more general than the required one. 



7 Conclusions 



Our proposal to incremental ACC aims at reducing the size of certificates and 
the checking time when a supplier provides an untrusted update of a (previously) 
validated package. Essentially, when a program is subject to an update, the in- 
cremental certificate we propose contains only the difference between the original 
certificate for the initial program and the new certificate for the updated one. 
Checking time is reduced by traversing only those parts of the abstraction which 
are affected by the changes rather than the whole abstraction. An important 
point to note is that our incremental approach requires the original certificate 
and the dependency arc table to be stored by the consumer side for upcoming 
updates. The appropriateness of using the incremental approach will therefore 
depend on the particular features of the consumer system and the frequency of 
software updates. In general, our approach seems to be more suitable when the 
consumer prefers to minimize as much as possible the waiting time for receiving 
and validating the certificate while storage requirements are not scarce. We be- 
lieve that, in everyday practice, time-consuming safety tests would be avoided by 
many users, while they would probably accept to store the safety certificate and 
dependencies associated to the package. Nevertheless, there can sometimes be 
situations where storage resources can be very limited, while runtime resources 
for performing upcoming checkings could still be sufficient. We are now in the 
process of extending the ACC implementation already available in the CiaoPP 
system to support incrcmcntality. Our preliminary results in certificate reduc- 
tion are very promising. We expect optimizations in the checking time similar 
to those achieved in the case of incremental analysis (see, e.g., [6]). 
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